It looks like this was a user error on my apart, abetted by an apparent bug in symbol-reference autocompletion. I had completely forgotten that the parameter naming rules for subscripts are different than for functions: subscript parameters don't take a label in the call unless you explicitly specify both a label and a local name in the declaration. So the type of the subscript declared public subscript(_ date: String, visit: CaseID) -> ValueOrMessage<Meeting> { ... } really is subscript(_:_:). not subscript(_:visit:). That explains why explicitly using the (::) worked. But it doesn't explain why the editor autocompletion wanted to give me (_:visit:). Anyway, changing the code declaration to public subscript(_ date: String, visit visit: CaseID) -> ValueOrMessage<Meeting> { ... } made the subscript work the way I expected, and made autocompletion work, too. BUT ... Roughly the same problem shows up with operator functions, and in this case, it looks like it may really be a DocC bug. Consider         public static func ==(_ lhs: Meeting.Item, _ rhs: Meeting.Item) -> Bool {...}         public static func <(_ lhs: Meeting.Item, _ rhs: Meeting.Item) -> Bool {...} and, in the documentation extension file, - ``<(_:_:)`` - ``==(_:_:)`` The equality declaration reference works as expected, and the apparently identical less-than declaration fails. In the Swift source, I get the diagnostic “Topic reference '%3C(%3A%3A)' couldn't be resolved. No local documentation matches this reference.” and in the documentation page the equality function shows up in my Ordering section, but the less-than function shows up in the auto-created Operators section.

No solution here. As far as I can tell, when SwiftUI instantiates or updates a List, it sets the bound selection variable to nil, and I have not been able to find any way to change this. For example, setting the selection variable in an .onAppear modifier on the list doesn't work, because SwiftUI apparently clears the selection after the onAppear action executes. I tried playing with the selection variable’s didSet property observer, but SwiftUI apparently clears the variable in a way that doesn’t trigger didSet. I’ve pretty much reached a dead end, too.

I think that it is assuming that the < might be the start of an HTML tag or some other sort of markup meta-character. Anyways, I have found that you can escape it (prefix it with a backslash: "<" to fix the problem. It makes the comment uglier to read in the code, but fixes the documentation markup problem.

What do you think attractive? What do you think better? What is the reason you think it is not attractive? (1) Having to separate the declaration and the initialization of a let constant is sometimes necessary, but always feels like a hack. One of the big advantages of guard is that I can initialize a let constant with an optional binding, without having to wrap the entire body of a function in an if statement. (2) A guard statement says immediately, “if his doesn't work, I’m out of here.” The do/catch requires a second look to determine that it’s really moral equivalent of a guard.

I meant to say that I have a struct whose initializer can throw an error.